Internet Protocol Made Accountable

The Internet design is vulnerable to numerous attacks, including source address spoofing, denial of service flooding, prefix hijacking, and route forgery attacks. Despite much research, this situation does not seem to improve: prefix hijacking or denial of service attacks continue to make headline news [10, 25]. This disheartening fact has prompted researchers to propose a radically different Internet architecture AIP [4] that replaces the aggregatable IP addresses with flat self-certifying addresses. Although promising, the AIP design is not without challenges. Chief among them is deployability. AIP requires an overhaul of the Internet Protocol (IP). All hosts and networks must be re-numbered. Applications must be revised to use AIP addresses. Hosts also need special hardware “smartNIC” to block DoS flooding traffic [4]. Every routing protocol, both intra-domain and inter-domain, must be revised to propagate AIP addresses, and routers must be upgraded to forward packets with AIP addresses. DNS must be extended to include AIP records, and so on. Moreover, AIP’s flat addresses prohibit CIDR-style address aggregation, which is a best current practice for scalable routing [15]. In this paper, we ask the question: can we design an Internet architecture that is as accountable as AIP but without its deployment and scalability tradeoffs? To this end, we explore a design that provides accountability into the Internet while retaining the IP addressing structure. We refer to this design as IPa+ (standing for accountability enhanced Internet Protocol). The IPa+ design uses the chain of trust embedded in the Internet address allocation process to bind an address prefix to an authorized Autonomous System’s (AS’s) public key. Since AS numbers are flat identifiers that do not impact routing scalability, the IPa+ design uses the hash of an AS’s public key as its self-certifying AS identifier in BGP. The IPa+ design uses DNSSEC [5, 7, 6, 23] to publish the secure bindings between an address prefix and its authorized AS’s public key, as DNSSEC is being rapidly deployed by Internet registries [12]. A signed record in the reverse DNS zone (in-addr.arpa) serves as a lightweight certificate that secures a prefix-to-key binding. Routers may distribute these lightweight certificates as BGP attributes to secure routing. This design removes a significant deployment hurdle for securing BGP [17], as it obviates the need for an Internet registry to maintain an additional public key infrastructure. The secure binding between a key and an IP address prefix bootstraps accountability in the network. It enables an AS to authenticate both its routing announcements and packets originated from its network. ASes can run a secure routing protocol (e.g., sBGP [18]) to authenticate its routing announcements and prevents prefix hijacking and route forgery attacks. It can then use a source authentication system [20] that piggybacks a Diffie-Hellman key exchange in secure BGP announcements to allow ASes to share pair-wise secret keys. A source AS may use this key to authenticate packets originated from its network with low overhead [20]. Source authentication makes a sender accountable for its actions. It further enables simple DoS solutions that block attack traffic near its sources [22,8,30], and secure congestion policing mechanisms that preventmalicious flows from congesting the network to starve legitimate communications. We evaluate the feasibility of IPa+ using data downloaded from regional Internet registries (RIRs) (§ 3). Our analysis shows that the load on the Internet registries is manageable, as the number of daily address prefix allocations at each RIR is small. We also present a preliminary comparison between IPa+ and AIP in terms of their security features, deployability, and scalability of IPa+ and AIP. Our study suggests that IPa+ provides nearly equivalent (if not stronger) security features to AIP and can be incrementally deployed on the IP network. It also requires fewer changes to the present Internet architecture, but some of the upgraded components (such as the access routers) in the IPa+ design implement more complicated functions.